These numbers sound great, thanks! I think we should use the colon (:) as the delimiter though. Afaik only NUL and : are forbidden in UNIX paths, a tab could occur in a path normally.

Try e.g.

require('fs').writeFileSync('/tmp/\t', 'asdf')

We talked about it, but just so it's written down - a : might not work on windows if the file is on another drive (D:/blabla)

These numbers sound great, thanks! I think we should use the colon (:) as the delimiter though. Afaik only NUL and : are forbidden in UNIX paths, a tab could occur in a path normally.

Yeah, I'd recommend using \0.

@scotthovestadt did you measure the impact in building the haste map or the full startup time? I imagine this can have an impact in the time to determine the tests to run (see https://github.com/facebook/jest/blob/master/packages/jest-resolve-dependencies/src/index.ts) as it resolves the dependencies of all the modules in the haste map. Maybe it'd be worth it to memoize the array (even in the same object, as it won't be persisted again).

@jeysal Will extract the delim to a var and use \0.

Considered memoizing but don't think it'll be worth it with the current access patterns.

I did test the haste map generation and while there might be a small hit it wasn't actually measurable because:

1. It's a relatively variable time already (it has a range of a couple seconds once you hit the threshold I'm benchmarking at).
2. The persist at the end is faster so that might be making up for the slower generation.

In any case, it can be optimized away by doing the join in the worker thread (which would introduce the complexity of detecting which type to avoid a breaking change). I didn't go there yet because I wasn't able to measure a difference by doing that... only pushing up changes where I can measure a significant difference. :)

@scotthovestadt my point is that if you only measure haste map build time you won't see that the cost might be transferring to a later stage in the process (in this case test determination). I'd try to measure the time it takes to get the list of tests that need to run when you use --findRelatedTests (see https://github.com/facebook/jest/blob/master/packages/jest-core/src/SearchSource.ts#L158). That should give you a good measure about the impact this could have in finding inverse dependencies and, if it's not negligible, try using memoization to reduce it.

Codecov Report

Merging #8171 into master will decrease coverage by <.01%.
The diff coverage is 50%.

@@            Coverage Diff             @@
##           master    #8171      +/-   ##
==========================================
- Coverage   62.28%   62.28%   -0.01%     
==========================================
  Files         265      265              
  Lines       10440    10435       -5     
  Branches     2538     2535       -3     
==========================================
- Hits         6503     6499       -4     
- Misses       3352     3354       +2     
+ Partials      585      582       -3

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c5fd7aa...c0de52e. Read the comment docs.

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.